Mobile Telecommunication

ABSTRACT

A node implementing an RLC (Radio Link Control) entity and being for use in a mobile communications system transmits a sequence of RLC SDUs (SDU=Service Data Unit) towards a peer node. As a result of re-establishment of an RLC entity not all SDUs may have been received. The peer notifies the node which is the next SDU that the peer expects to receive (by transmitting the next SDU number to the node). The node resumes transmission from that SDU onwards. This may or may not lead to re-transmission of SDUs transmitted before the RLC re-establishment. As an alternative, the peer does not notify the node of the next SDU that it expects to receive, but instead the node re-transmits any unacknowledged SDUs, together with the SDU number of the first re-transmitted SDU. The peer then discards any duplicate SDUs. Both variants enable lossless data transfer whilst avoiding duplication.

The present invention relates to mobile telecommunication, in particularto RLC (Radio Link Control) Re-establishment, e.g. required due to anRLC PDU size change (RLC=Radio Link Control, PDU=Protocol Data Unit).

In the past, there has not been a particular need ever to change the PDUsize. However, more recently a need for changing the PDU size hasemerged. For example, the maximum throughput on HS-DSCH (HighSpeed-Downlink Shared Channel) is limited by the RLC PDU size. Withlarger PDU sizes on HS-DSCH the throughput can be increased. However,when switching to normal DCH (Dedicated Channel) or FACH (Forward AccessChannel) the currently used RLC PDU size of 320 bits would preferably beused.

A similar situation may occur for the enhanced uplink, currently underdevelopment by 3GPP (The Third Generation Partnership Project), althoughin this case there is instead a desire to use a smaller PDU size thanthe standard 320 bit in order to have a larger coverage (the 320 bit RLCPDU gives a minimum data rate of 160 kbit/s with a 2 ms transmissiontime interval which is considered for the enhanced uplink, which maylead to insufficient coverage).

Hence a need has emerged to change the RLC PDU size for an ongoingconnection, especially when switching between HS-DSCH, DCH (or FACH) andEnhanced Uplink Dedicated Channel.

According to 3GPP R-99/4/5, the RLC PDU size can be reconfigured for anongoing connection, i.e. for an existing radio bearer. When the PDU sizeis reconfigured the RLC protocol is re-established.

The present inventor has appreciated that the procedures which arecurrently in use may lead to data loss.

When the RLC PDU size is reconfigured in R-99/4/5, an RLC entity (or RLCentities) in the UE (User Equipment, e.g. a mobile telephone) and theRNC (Radio Network Controller) is/are re-established since AM RLC(AM=Acknowledged Mode) can only have one PDU size at a given time. Afterthe re-establishment the RLC sequence numbers start from zero.

The inventor has appreciated that a problem arises in connection withthose RLC PDUs which have been transmitted before the re-establishmentbut have not yet been acknowledged. Since the transmitter has not yetreceived any ACK (Acknowledgement) for these PDUs it is not known if theSDUs contained in the PDUs have been received in the peer entity or not(SDU=Service Data Unit).

Regarding the relationship between SDUs and PDUs, it will be appreciatedthat the SDUs are received from higher layers. The size of the SDUs mayvary, whereas the PDUs all have the same size (although the PDU size canbe changed, but is then changed for all PDUs). The RLC segments and/orconcatenates the SDUs into PDUs and it is the PDUs that are transmittedover the air, even if in the present specification reference is made totransmitted/received SDUs. An SDU can be regarded astransmitted/received if all PDUs containing segments of that SDU havebeen transmitted/received.

The transmitter could resegment the unacknowledged SDUs into new PDUs(with SNs (Sequence Numbers) starting from zero). This would mean thatthose SDUs which had, in fact, been received before the re-establishment(but not yet acknowledged) are received twice in the peer entity,thereby leading to duplicate reception of SDUs. Alternatively, thetransmitter could discard the unacknowledged SDUs (on the assumptionthat they have, in fact, been received before the re-establishment)without re-transmitting them after the re-establishment. This wouldavoid any duplicate reception of SDUs but would instead lead to loss ofdata (in case not all unacknowledged SDUs were received before there-establishment).

In other words, it has hitherto not been possible to guarantee bothlossless data transfer and duplicate avoidance of SDUs at RLCre-establishment.

It is noted that in currently implemented systems any unacknowledged RLCPDUs in both the transmitter and the receiver are discarded atre-establishment, i.e. there is a risk of loss of data.

It is an aim of at least the preferred embodiments of the presentinvention to overcome this problem.

In a first aspect the present invention provides a method of operating anode implementing an RLC entity and being for use in a mobilecommunications system, the method comprising:

-   -   transmitting a sequence of RLC SDUs towards a peer node; and    -   as a result of re-establishment of an RLC entity:        -   receiving from the peer node a request for re-transmission            of at least one RLC SDU of said sequence; and        -   re-transmitting said at least one RLC SDU of said sequence            towards the peer node.

This first aspect is directed at the functionality of the node (e.g. anRNC or a UE) transmitting SDUs towards a peer node (e.g. the other of anRNC and a UTE), i.e. it primarily relates to the “transmitting end” of anode/peer node combination.

In preferred embodiments of this aspect the node receives from the peernode a request to re-transmit the first SDU which has not yet beenreceived by the peer node, and the node then re-transmits this SDU andany subsequent SDUs.

In embodiments of the invention the peer node checks which SDU is thenext one to be transmitted. It may be that all SDUs transmitted by thenode have been received by the peer node, in which case there is no needfor any retransmission. In this case the next SDU to be transmitted isan SDU which the node has not yet transmitted, so in this casetransmission is simply resumed after the re-establishment (withoutre-transmission of SDUs). That is, when the node receives the requestfrom the peer node for the next SDU the node checks if any SDUs alreadytransmitted need to be re-transmitted.

In a second, closely related aspect, the present invention provides amethod of operating a node implementing an RLC entity and being for usein a mobile communications system, the method comprising:

-   -   receiving, from a peer node, a sequence of RLC SDUs; and    -   as a result of re-establishment of an RLC entity:        -   requesting the peer node to re-transmit at least one RLC SDU            of said sequence; and        -   receiving, from the peer node, said at least one            re-transmitted RLC SDU.

This second aspect is directed at the functionality of the node (e.g. anRNC or a UE) receiving SDUs from a peer node (e.g. the other of an RNCand a UE), i.e. it relates to the “receiving end” of a node/peer nodecombination and can hence be regarded as complementary to the firstaspect.

In preferred embodiments of this aspect the node transmits to the peernode a request to re-transmit the first SDU which has not yet beenreceived by the node, and the peer node then re-transmits this SDU andany subsequent SDUs.

The present invention also provides a combination of the first andsecond aspects, although it will be appreciated that the terms “node”and “peer node” would have to be swapped in one of the aspects. In otherwords, the combination describes the functionality of both the“transmitting end” and the “receiving end”.

Whilst according to the first and second aspects a request forretransmission of one or more SDUs is transmitted/received, it issimilarly possible for the “transmitting end” to re-transmit allunacknowledged SDUs and to let the “receiving end” know which SDUs arebeing re-transmitted. The “receiving end” can then identify anyduplicate SDUs and discard these.

Hence, in a third aspect closely related to the first and second aspectsthe present invention provides a method of operating a node implementingan RLC entity and being for use in a mobile communications system, themethod comprising:

-   -   transmitting a sequence of RLC SDUs towards a peer node; and    -   as a result of re-establishment of an RLC entity:        -   identifying at least one RLC SDU for which no            acknowledgement has yet been received by the node;        -   re-transmitting said at least one RLC SDU towards the peer            node; and        -   transmitting to the peer node an identification of the at            least one RLC SDU which is being re-transmitted.

This third aspect is again directed at the functionality of the node(e.g. an RNC or a UE) transmitting SDUs towards a peer node (e.g. theother of an RNC and a UE), i.e. it primarily relates to the“transmitting end” of a node/peer node combination.

In preferred embodiments of this aspect the node identifies anyunacknowledged SDUs and retransmits these. It also notifies the peernode which SDUs are being retransmitted so that the peer node candiscard any duplicate SDUs.

In a fourth aspect (which can be regarded as complementary to the thirdaspect), the present invention provides a method of operating a nodeimplementing an RLC entity and being for use in a mobile communicationssystem, the method, comprising:

-   -   receiving, from a peer node, a sequence of RLC SDUs; and    -   as a result of re-establishment of an RLC entity:        -   receiving, from the peer node, at least one re-transmitted            RLC SDU of said sequence; and        -   receiving, from the peer node, an identification of the at            least one RLC SDU which is being re-transmitted.

This fourth aspect is again directed at the functionality of the node(e.g. an RNC or a UE) receiving SDUs from a peer node (e.g. the other ofan RNC and a UE), i.e. it relates to the “receiving end” of a node/peernode combination.

In preferred embodiments of this aspect the node receives from the peernode re-transmitted SDUs and an identification of the re-transmittedSDUs (which the peer node has identified as unacknowledged) so that thenode can discard any duplicate SDUs.

The present invention also provides a combination of the third andfourth aspects, although it will be appreciated that the terms “node”and “peer node” would again have to be swapped in one of the aspects. Inother words, also this combination describes the functionality of boththe “transmitting end” and the “receiving end”.

Preferred features are set out in the dependent claims. Apparatusaspects corresponding to method aspects disclosed herein are alsoprovided, and vice versa.

Some preferred embodiments of the invention will now be described by wayof example only and with reference to the accompanying drawing, inwhich:

The single FIGURE illustrates features of the method according toembodiments of the invention.

Pursuant to embodiments of the invention it is envisaged that the SDUsare numbered with sequence numbers (SDU numbers), preferably PDCP(Packet Data Convergence Protocol) sequence numbers. Both thetransmitter and the receiver keep counters that are incremented for eachtransmitted and received SDU. Once the counters in the transmitter andreceiver have been synchronised the sequence numbers do not need to betransmitted.

A first embodiment will now be described with reference to the FIGURE.We will first consider the case of downlink transmission, i.e.transmission of SDUs from an RNC to a UE. Hence the left part of theFIGURE shows SDUs (to be) transmitted by the RNC and the right part ofthe FIGURE shows SDUs (to be) received by the UE. The RNC numbers eachtransmitted SDU and the UE numbers each received SDU. These are shown inthe FIGURE. Each numbered box in the FIGURE represents a PDU. In theexample several PDUs are being grouped to form an SDU, but in practice asegment of an SDU, one complete SDU or several SDUs can be included intoone PDU depending on the size of the SDU and the PDU. Boxes marked withan asterisk (*) represent PDUs which have been transmitted/received andboxes without asterisk represent PDUs which have not yet beentransmitted/received. An SDU is considered to be transmitted (received)when all PDUs containing segments of the SDU have been received.

In the example, PDUs 10 to 17 have been transmitted. Out of thetransmitted PDUs, PDU 13 has not been received. The transmitter hasreceived acknowledgements for PDUs up to and including PDU 9. Since thereceiver has received all PDUs containing segments of SDU 4 (PDU 10-12),SDU 4 has been delivered to higher layers.

We first consider the case of in-sequence-delivery by the receiver.Although SDU 6 has been received completely, it is not delivered tohigher layers since SDU 5 has not yet been (completely) received.

When the RNC requests a re-establishment (e.g. required due to a PDUsize change) it indicates to the UE from which SDU number it will starttransmitting after the re-establishment. This can conveniently be donein a reconfiguration message, in particular an RRC (Radio ResourceControl) reconfiguration message (e.g. RADIO BEARER RECONFIGURATIONmessage). The message contains a SN set to 4 so as to indicate to the UEthat SDU 4 is the first SDU that the RNC will transmit after there-establishment.

If the SDU number contained in the message is lower than the number ofan SDU which the UE has already received and delivered to higher layersthe UE knows that a number of SDUs transmitted after there-establishment are duplicates and should be ignored. In the example,after the re-establishment the RNC resegments SDUs 4 and onwards intoPDUs with the new PDU size with RLC sequence numbers starting from zero.Since the UE knows that it has already received SDU 4 and delivered itto higher layers it can discard that SDU when it is received as a resultof the re-transmission.

On the other hand, any SDUs received as a result of re-transmission andhaving a SN which is higher than the highest SDU number which has beendelivered to higher layers will not be discarded. This is the case forSDU 5 and onwards. In this way both lossless data transfer and duplicatedetection/duplicate avoidance can be achieved.

In a variant, if in-sequence-delivery is not configured, SDU 6 may alsohave been delivered to higher layers at the time of re-establishmentsince it has been completely received. In this case, the UE would alsodiscard this SDU upon reception after the re-establishment. To enable UEto do this it is provided with a memory facility which stores thenumbers of SDUs which have (recently) been delivered to higher layers.

In the uplink case the function is similar to that of the downlink case:The UE includes in a reconfiguration complete message (RRCreconfiguration complete message, e.g. RADIO BEARER RECONFIGURATIONCOMPLETE message) the SDU number of that SDU from which (re-)transmission after the re-establishment will start, and correspondingsteps as in the downlink case are performed.

It is noted that without the invention, the UE would not know that SDU 4transmitted after the re-establishment is a copy of an already receivedSDU and would therefore deliver it twice to higher layers.

A second embodiment will now be described, still with reference to theFIGURE. Whilst in the first embodiment the transmitter re-transmits anyunacknowledged SDUs and sends the SDU number of the first SDU that itre-transmits (SDU 4 in the example), it is possible, according to thesecond embodiment, for the receiver to indicate to the transmitter fromwhich SDU onwards the (re-)transmission should start. The receiver wouldcheck if all SDUs up to the SDU with the highest SDU number have beenreceived. If not all SDUs up to and including the highest-numbered SDUhave been received then the receiver would request transmission from thelowest-numbered non-received SDU onwards. In the example, the receiverwould indicate to the transmitter that the transmitter should transmitfrom SDU 5 onwards. This indication could be included in thereconfiguration complete message for the downlink case (the RNC beingthe transmitter, the UE being the receiver) and in the reconfigurationmessage for the uplink case (the UE being the transmitter, the RNC beingthe receiver).

If on the other hand SDU 5 had also been received by the UE the UE wouldrequest transmission to start from SDU 7 onwards, so in this case therewould be no re-transmission.

In other words, in this embodiment the receiver indicates to thetransmitter the first SDU that the receiver expects to receive after there-establishment. The transmitter then resumes transmission after there-establishment from that SDU onwards. This may or may not lead tore-transmission of any SDUs already transmitted.

Pursuant to both embodiments it is possible to change the RLC PDU size(or make RLC re-establishments for other reasons, e.g. as a consequenceof an RLC protocol error such as an RLC unrecoverable error) whilemaintaining both lossless data transfer and duplication avoidance.

It is noted that the above embodiments relate to processes which takeplace between an RNC and a UE associated with that RNC, i.e. processeswhich are controlled by a single RNC.

It is also noted that references to “re-establishment of an RLC entity”do not necessarily mean that the complete RLC entity has to bere-established. It is possible e.g. to change the PDU size only for thedownlink, in which case it would be possible only to re-establish thetransmitter side of the RNC and the receiver side of the UE.

Although the invention has been described in terms of preferredembodiments as set forth above, it should be understood that theseembodiments are illustrative only and that the claims are not limited tothose embodiments. Those skilled in the art will be able to makemodifications and alternatives in view of the disclosure which arecontemplated as falling within the scope of the appended claims. Eachfeature disclosed or illustrated in the present specification may beincorporated in the invention, whether alone or in any appropriatecombination with any other feature disclosed or illustrated herein.

1-40. (canceled)
 41. A node implementing an RLC (Radio Link Control)entity and being for use in a mobile communications system, the nodecomprising means for transmitting a sequence of RLC SDUs (RLC=Radio LinkControl, SDU=Service Data Unit) towards-a peer node; wherein the node isarranged, as a result of re-establishment of an RLC entity, to: receivefrom the peer node a request for re-transmission of at least one RLC SDUof said sequence; and re-transmit said at least one RLC SDU of saidsequence towards the peer node.
 42. A node according to claim 41,wherein the RLC re-establishment is required due to an RLC PDU(RLC=Radio Link Control, PDU=Protocol Data Unit) size change.
 43. A nodeaccording to claim 41, wherein the RLC re-establishment is required dueto an RLC protocol error.
 44. A node according to claim 41, wherein saidrequest comprises the SDU sequence number of said at least one RLC SDUof said sequence, and the node is arranged to identify, based on saidSDU sequence number, which RLC SDU(s) need(s) to be re-transmitted. 45.A node according to claim 44, wherein the node is arranged tore-transmit all RLC SDUs subsequent to, and including, that RLC SDUwhose SDU sequence number is comprised in said request.
 46. A nodeaccording to claim 41, wherein the node comprises an RNC (Radio NetworkController) and the peer node comprises a UE (User Equipment).
 47. Anode according to claim 46, wherein said request is arranged to bereceived in a RRC (Radio Resource Control) reconfiguration completemessage.
 48. A node according to claim 41, wherein the node comprises aUE and the peer node comprises an RNC.
 49. A node according to claim 48,wherein said request is arranged to be received in a RRC reconfigurationmessage.
 50. A node implementing an RLC entity and being for use in amobile communications system, the node comprising means for receiving,from a peer node, a sequence of RLC SDUs; wherein the node is arranged,as a result of re-establishment of an RLC entity, to: request the peernode to re-transmit at least one RLC SDU of said sequence; and receive,from the peer node, said at least one re-transmitted RLC SDU.
 51. A nodeaccording to claim 50, further comprising means for determining thefirst RLC SDU of said sequence which has not yet been received, whereinthe node is arranged to request the peer node to re-transmit the firstRLC SDU of said sequence which has not yet been received.
 52. A nodeaccording to claim 50, further comprising means for discarding those ofthe re-transmitted RLC SDUs which had already been received before there-transmittal.
 53. A node according to claim 50, further comprisingmeans for discarding those of the re-transmitted RLC SDUs which hadalready been delivered to higher layers.
 54. A node according to claim50, wherein the node is arranged to transmit said request in a RRCreconfiguration message.
 55. A node according to claim 50, wherein thenode is arranged to transmit said request in a RRC reconfigurationcomplete message.
 56. A system comprising: a node according to claim 41;and said peer node, wherein said peer node implements an RLC entity andis for use in the mobile communications system, the peer node comprisingmeans for receiving, from the node, the sequence of RLC SDUs; whereinthe peer node is arranged, as a result of said re-establishment, to:request the node to re-transmit said at least one RLC SDU of saidsequence; and receive, from the node, said at least one re-transmittedRLC SDU.
 57. A node implementing an RLC entity and being for use in amobile communications system, the node comprising means for transmittinga sequence of RLC SDUs towards a peer node; wherein the node isarranged, as a result of re-establishment of an RLC entity, to: identifyat least one RLC SDU for which no acknowledgement has yet been receivedby the node; re-transmit said at least one RLC SDU towards the peernode; and transmit to the peer node an identification of the at leastone RLC SDU which is being re-transmitted.
 58. A node according to claim57, wherein transmitting said identification comprises transmitting tothe peer node the SDU sequence number of said at least one RLC SDU,whereby the peer node can determine, using the SDU sequence numbers,whether said at least one re-transmitted RLC SDU had already beenreceived by the receiver as a result of the transmission of the sequenceof RLC SDUs.
 59. A node according to claim 58, wherein saididentification comprises the SDU sequence number of the firstre-transmitted RLC SDU.
 60. A node according to claim 57, wherein saididentification is transmitted in a RRC reconfiguration message.
 61. Anode according to claim 57, wherein the node is arranged to transmitsaid identification in a RRC reconfiguration complete message.
 62. Anode implementing an RLC entity and being for use in a mobilecommunications system, the node comprising means for receiving, from apeer node, a sequence of RLC SDUs; wherein the node is arranged, as aresult of re-establishment of an RLC entity, to: receive, from the peernode, at least one re-transmitted RLC SDU of said sequence; and receive,from the peer node, an identification of the at least one RLC SDU whichis being re-transmitted.
 63. A node according to claim 62, furthercomprising means for determining, using the SDU sequence numbers,whether said at least one re-transmitted RLC SDU had already beenreceived by the node as a result of the transmission of the sequence ofRLC SDUs.
 64. A node according to claim 62, wherein said identificationis arranged to be received in a RRC reconfiguration complete message.65. A node according to claim 62, wherein said identification isarranged to be received in a RRC reconfiguration message.
 66. A systemcomprising: a node according to claim 57; and said peer node, whereinsaid peer node implements an RLC entity and is for use in the mobilecommunications system, the peer node comprising means for receiving,from the node, said sequence of RLC SDUs; wherein the peer node isarranged, as a result of said re-establishment, to: receive, from thenode, said at least one re-transmitted RLC SDU of said sequence; andreceive, from the node, said identification of said at least one RLC SDUwhich is being re-transmitted.
 67. A method of operating a nodeimplementing an RLC (Radio Link Control) entity and being for use in amobile communications system, the method comprising: transmitting asequence of RLC SDUs (RLC=Radio Link Control, SDU=Service Data Unit)towards a peer node; and as a result of re-establishment of an RLCentity: receiving from the peer node a request for re-transmission of atleast one RLC SDU of said sequence; and re-transmitting said at leastone RLC SDU of said sequence towards the peer node.
 68. A method ofoperating a node implementing an RLC entity and being for use in amobile communications system, the method comprising: receiving, from apeer node, a sequence of RLC SDUs; and as a result of re-establishmentof an RLC entity: requesting the peer node to re-transmit at least oneRLC SDU of said sequence; and receiving, from the peer node, said atleast one re-transmitted RLC SDU.
 69. A method of operating a nodeimplementing an RLC entity and being for use in a mobile communicationssystem, the method comprising: transmitting a sequence of RLC SDUstowards a peer node; and as a result of re-establishment of an RLCentity: identifying at least one RLC SDU for which no acknowledgementhas yet been received by the node; re-transmitting said at least one RLCSDU towards the peer node; and transmitting to the peer node anidentification of the at least one RLC SDU which is beingre-transmitted.
 70. A method of operating a node implementing an RLCentity and being for use in a mobile communications system, the method,comprising: receiving, from a peer node, a sequence of RLC SDUs; and asa result of re-establishment of an RLC entity: receiving, from the peernode, at least one re-transmitted RLC SDU of said sequence; andreceiving, from the peer node, an identification of the at least one RLCSDU which is being re-transmitted.